docs(fields): record the measured browser reading behind CurrencyField/PercentField - #6777

Part of #6765

Deliberately not Fixes: this PR carries the measurement the card asked for and the
half of the answer that is not a judgment call. The other half — whether the silent drop
this measurement reproduced should be announced — is escalated below and needs a ruling,
so the card must stay open.

Step 1: the measurement the card explicitly did not make

#6765 measured that happy-dom, this package's test environment, does not implement the
HTML number-input value-sanitization algorithm, and concluded that any test written for
these two widgets exercises a code path no browser takes. It was explicit that it had
not measured the real browser, and had not reproduced a user-visible defect.

Measured now: Chromium 141.0.7390.37 via Playwright 1.62.1, executablePath
/opt/pw-browsers/chromium, driving the real widgets mounted from source in a real
page (a Vite harness, not committed), through every delivery route a user has —
keystrokes, Ctrl+V paste with a real clipboard on a secure origin, keyboard.insertText,
and a programmatic value set.

The real-browser table — the widgets, not a bare input

Programmatic sets sanitize exactly as the spec says: el.value = "12abc" leaves "".

Which fork this selects, and the correction it forces

Sanitization holds — and the card's predicted consequence does not.

The card reasoned that if sanitization held, residue would degrade to the empty string and
onChange(null). Measured, 12abc / 1.2.3 / 0x10 never take that route. The browser
filters the keystroke or the paste before the change event fires, so what arrives is a
different, already well-formed number: "12", "1.23", "010".

The load-bearing consequence: residue never reaches these two widgets in a real
browser. #6715's anchored WHOLE_NUMBER_TEXT — the right answer for LocationField,
a type="text" box with nothing filtering it — would here accept every string these boxes
can produce and reject only strings the test environment fabricates. Adding it would be a
no-op in the product whose only observable effect is making a happy-dom test go green over
a branch no user executes, and it would pin a truncation nobody reaches. That is the
outcome the dispatch fenced off, so it is not added.

The oracle really does disagree with the product

Six of ten cases disagree. A pin written in this environment asserting 0x10 yields 0
would assert the exact opposite of the product, which yields 10.

What is in this PR

• CurrencyField.tsx, PercentField.tsx — the measurement recorded at the parseFloat
  sites, with the explicit note that finding(fields): LocationField accepts a partly-numeric coordinate, emitting a plausible wrong location #6715's guard is deliberately not copied and why.
  Comment-only: 78 inserted lines, 0 deletions, and every inserted line is a comment
  (git diff -U0 | grep -v '^+\s*\(\*\|//\|/\*\*\)' is empty). Behaviour unchanged.
• NumberInputWidgets.environmentDivergence.test.tsx — 16 tests pinning the divergence:
  that happy-dom does not sanitize, that it nevertheless reports validity.badInput
  correctly, that the platform already calls every measured browser reading a whole number
  and every residue string bad input, and the per-widget oracle-vs-product table above.
• An empty-frontmatter changeset — internal only, releases nothing (this repo's
  first-class way to declare that; the skip-changeset label is deliberately not used
  here, it reads nothing in this repo).

The unreachability assertion uses the platform's own validity.badInput rather than a
transcription of #6715's regex. That regex is module-private to LocationField.tsx, this
card is fenced out of editing that file to export it, and copying its source would create
the second dialect of "what a number is" AGENTS.md #0.1 forbids. badInput is also the
one signal on this surface that happy-dom and Chromium were measured to agree on.

Escalated, not fixed: the silent drop is real

The card listed "whether a silent drop is worth announcing" as unmeasured. The drop itself
is now reproduced: typing 1e leaves Chromium visibly displaying 1e while
.value reads ""; the widget emits null, aria-invalid stays "false", and zero
diagnostics render. Pasting 1e into an empty box is worse — React sees no value change
and fires nothing at all, so the model keeps its previous value while the box shows text
that contradicts it. That is #6716's class.

It is not fixed here, for two measured reasons rather than as a scope dodge:

1. The same drop belongs to every type="number" widget in this package —
   NumberField and GeolocationField read the box the same way. Announcing in two of
   four is a widget-class decision, not a patch.
2. The truncating rows (1.2.3 becoming 1.23) cannot be refused by any widget-side
   guard at all — the information is gone before handleChange runs. Announcing on
   badInput while 1.2.3 still stores silently teaches users that no warning means the
   value is right, which is exactly when it is not. Refusing those too means abandoning
   type="number" for type="text" plus own parsing, which reverses Record-level inline edit polish (follow-up to #2407): expanded-value passthrough, approval-lock preflight, numeric inputs, edit-CTA state, keyboard shortcuts #2572's deliberate
   min/max/step affordances.

Options and a recommendation are in the report on #6765.

Verification

All heavy runs serialized through the shared verify lock. Union re-run on the shipping
commit 816e3b824, chained with && so the wrapper verdict certifies every part.

The dependency closure was built first (pnpm --workspace-concurrency=2 --filter "@object-ui/fields^..." build) — without it tsc reports 100+ TS2307 Cannot find module
errors that are a fresh-worktree prerequisite failure, not a red gate.

Ablation, run on this commit to show the new pin measures the widget rather than
restating a constant table: swapping parseFloat for Number in CurrencyField's change
handler. Mutation confirmed on disk by grep counts before reading anything
(parseFloat-form 1 to 0, Number-form 0 to 1); no rebuild needed and none skipped,
because the test imports ../widgets/CurrencyField — a relative source import, with no
dist/ in the resolution path. Inner vitest exit 1, red on exactly the four currency
cases: expected NaN to be 12, expected NaN to be 1.2, expected 16 to be +0 (the
Number('0x10') reading #6715 rejected on measurement), expected NaN to be 1. Percent
untouched, as predicted. Restored under a trap ... EXIT INT TERM with absolute paths via
git checkout HEAD -- "$REPO_ROOT/...", and the restore proven by an empty
git diff HEAD, not by an exit code.

Generated by Claude Code

Generated by Claude Code